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INITIAL CONNECTION PROTOCOL--REVIEWED 


INTRODUCTION 


At the Network meeting preceding the SJCC ’71, an 
"ICP Committee" was established. It’s purpose was to get 
"something" working fast with minimum modifications to the 
current ICP so as to minimize complaints. (This seems like 
a good definition for almost everything!) Consequently, 
those who had objections to the current ICP were interviewed 
and a compromise was reached in the form of RFC #165. The 
ICP committee didn’t have a chance to think about an alter- 
native because of the above mentioned constraints. In this 
note we attempted a simple version of an ICP assuming that 
we can add commands to Host-Host protocol. We hope that this 
will be useful in the design of the next version of the 
Host-—Host protocol. 


ICP COMMANDS 


To establish a regular connection one party can issue 
an INIT (NCP sends RTS or STR commands), then the other 
party can accept the request for connection by responding 
with an INIT or refusing it with a CLOSE. We think that 
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a similar, simple mechanism is desirable for the ICP. 
Furthermore, the ICP should allow for simplex as well as 
duplex connections from user to server. 


The following commands are necessary for simplex 
connections: 


ISC - Initiate Simplex Connection 
ASC - Accept Simplex Connection 
RSC - Refuse Simplex Connection 


The notation for parameters is similar to that 
of RFC #165: 


L - Server socket name, in one special case the 
server is "logger". 


U - User socket. 


S - Socket assigned by server for the connection 
with user. 


XxX - Is the byte size if U is odd and is the link 
number if U is even. 


X - Is the complement of X (X is the link number 
if U is odd and byte size if U is even. 


To initiate a simplex connection the user’s NCP 
issues: 
ISC; L, Up X 


To refuse this connection the server’s NCP issues: 


RSC, L, U 
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To accept this connection the server’s NCP issues: 
ASC, L, U, S, X 

Similarly, for duplex connections, we have: 
IDC, L, Ul, X1, U2, X2 
RDC, L, Ul, U2 


ADC, L, Ul, S1, X1, U2, S2, X2 


where (U1,U2), (S1,S2), (U1,S1) and (U2,S2) are pairs of 
opposite gender. 


After the server accepts the connection(s), it (they) 
goes immediately to a "connected state", and the appropriate 
ALL command (s) must be sent. 


ADVANTAGES 


The main advantage to this approach is that it mini- 
mizes the dialog between user and server. The server socket 
L is used only as an address, not a socket to connect to, 
therefore eliminating the need to establish a connection to 
L, choose a byte size, send an ALL command, send and receive 
data on it and CLOSE it. Race conditions as mentioned in 
RFC #143 do not arise. Socket L is the server and should 
be in a "Listening for ICP" state when an ISC or IDC is 
received. If socket L is not in that state, the serving 
NCP should refuse to ICP request. The serving NCP should 
_not_ queue ICP requests. 

In the current ICP, when the user choses socket U, he 
has to reserve sockets U+2 and U+3. In the above described 
approach no restrictions exist for Ul and U2 (except that 
they are of opposite gender); the same is true for S1 and 
S2. 


We think that duplex commands are necessary since both 
connections are to be connected to the same server process. 
Their separation by using two ISCs, will add complications 
of correlating the two ISCs with the same process. Also, 
if two ISCs are used, the first might be accepted and the 
second refused. This leads to uncertainty on the user’s 
part. This condition cannot occur with the duplex commands. 
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MINIMUM MODIFICATION TO CURRENT ICP 


The minimum change we can think of to make the current 
ICP look similar to the above is to add one NCP level com- 
mand -- accept: 


ACC, L, U, S 


The exchange between NCPs in the notation of RFC #165 
is now: 
<where the original uses a script lowercase "L" we use "1"> 
<where the original uses subscripts we use {} so that 
A-subscript-B is printed A{B} > 


Server NCP User NCP 


Listen for connection on L RST,U,L,1{A} 


ACC,L,U,S S is passed by NCP to the 
user and connection from 
U to L is closed. 


STR, S+1,U+2,B{s} STR, U+3,S,B{u} 

RTS, S,U+3,1{B} RTS, U+2,S+1,1{c} 
Wait for connection Wait for connection 
ALL, 1{B},m{B},b{B} ALL, l{c},m{c},b{c} 


An alternative way to the ACC command is a CLS command 
with an additional parameter (32 bits long). If parameter 
is zero the request for connection by the user is refused; 
if the parameter is non-zero, the request is accepted and 
socket S is the value of the parameter. 


All suggested changes improve the ICP dialog both from 


the aesthetic and efficiency points of view. We lean strongly, 
however, to the first, more major ICP modification. 
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A COMMENT ABOUT CLS COMMAND 


It seems appropriate to mention here for the purpose 
of the next version of the Host-Host protocol that the 
CLS command has more than one function. We think that the 
CLS command should be reserved to close connections in the 
"connected state" only (i.e., "open" connections). Two 
additional commands can be used for "refusing" and "reject— 
ing" requests for connections: 


REJ<mysocket><yoursocket> -- when a request 
for connection is rejected unconditionally. 


REF<mysocket><yoursocket><reason> -- when a 
request for connection is refused temporarily 
because the NCP could not handle it. For 
example: no process LISTENed to it and it 

was timed-out, or NCP tables are full in which 
case the user process may try again. The 
reason for refusing is indicated in the 
parameter "reason". 


[ This RFC was put into machine readable form for entry ] 
[ into the online RFC archives by BBN Corp. under the ] 
[ direction of Alex McKenzie. 12/96 ] 
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